lib,src,test,doc: add node:ffi module#62072
Conversation
|
Review requested:
|
|
Yes |
Qard
left a comment
There was a problem hiding this comment.
Looks very cool! I'm glad to see someone has picked this back up. 🙂
I did a quick review and it all looks good. My only comment is there seems to be a bunch of static strings and a private symbol which we might want to define in env_properties.h.
9462e4d to
631d73a
Compare
Failed to start CI⚠ No approving reviews found ✘ Refusing to run CI on potentially unsafe PRhttps://github.com/nodejs/node/actions/runs/23272564448 |
|
@anonrig I cancelled that CI run to save resources. I started https://ci.nodejs.org/job/node-test-pull-request/71877/ manually, and it's currently running. |
given that this is still draft and @cjihrig indicated it's not ready for review, a sign off is not yet appropriate.
given that this is still draft and @cjihrig indicated it's not ready for review, a sign off is not yet appropriate.
|
@cjihrig @ShogunPanda this now conflicts, can you rebase? |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #62072 +/- ##
==========================================
- Coverage 89.71% 89.66% -0.06%
==========================================
Files 695 706 +11
Lines 214546 217789 +3243
Branches 41082 41665 +583
==========================================
+ Hits 192487 195279 +2792
- Misses 14116 14439 +323
- Partials 7943 8071 +128
🚀 New features to boost your workflow:
|
* src,deps,test: various improvements Signed-off-by: Paolo Insogna <paolo@cowtech.it> * deps,test: fixed failures Signed-off-by: Paolo Insogna <paolo@cowtech.it> * deps,test: fixed failures Signed-off-by: Paolo Insogna <paolo@cowtech.it> * deps,test: fixed failures Signed-off-by: Paolo Insogna <paolo@cowtech.it> * deps,test: fixed failures Signed-off-by: Paolo Insogna <paolo@cowtech.it> * doc,lib: fixed failures Signed-off-by: Paolo Insogna <paolo@cowtech.it> * deps: fixed failures Signed-off-by: Paolo Insogna <paolo@cowtech.it> * test: fixed failures Signed-off-by: Paolo Insogna <paolo@cowtech.it> --------- Signed-off-by: Paolo Insogna <paolo@cowtech.it>
* test: fixed build on Windows Signed-off-by: Paolo Insogna <paolo@cowtech.it> * test: fixed build on Windows Signed-off-by: Paolo Insogna <paolo@cowtech.it> * test: fixed build on Windows Signed-off-by: Paolo Insogna <paolo@cowtech.it> * test: fixed build on Windows Signed-off-by: Paolo Insogna <paolo@cowtech.it> * test: removed useless file Signed-off-by: Paolo Insogna <paolo@cowtech.it> --------- Signed-off-by: Paolo Insogna <paolo@cowtech.it>
Signed-off-by: Paolo Insogna <paolo@cowtech.it>
Signed-off-by: Paolo Insogna <paolo@cowtech.it>
Signed-off-by: Paolo Insogna <paolo@cowtech.it>
Signed-off-by: Paolo Insogna <paolo@cowtech.it>
Signed-off-by: Paolo Insogna <paolo@cowtech.it>
Signed-off-by: Paolo Insogna <paolo@cowtech.it>
Signed-off-by: Paolo Insogna <paolo@cowtech.it>
| Other targets require building Node.js against a shared libffi with | ||
| `--shared-ffi`. The unofficial GN build does not support `node:ffi`. | ||
|
|
||
| When using the [Permission Model][], FFI APIs are |
There was a problem hiding this comment.
Should permissions have an option to restrict which files or symbols can be loaded?
There was a problem hiding this comment.
I don't think so, it could potentially be a very long list.
Anyway, I'm open to reconsider this in a future PR, but I think we can start with this as a starting point.
| Supported type names: | ||
|
|
||
| * `void` | ||
| * `i8`, `int8` |
There was a problem hiding this comment.
Why introduce any aliases? Seems like extra mental overhead to remember that there's two ways to spell the same thing?
Should we export a constant with available types?
There was a problem hiding this comment.
About the first question: it's to make transition smooth from other languages or runtime. You don't have to remember both, you just use what you already know.
About the second: that's a good suggestion. I will add it!
There was a problem hiding this comment.
IMO while aliases make writing code easier and more familiar (you write what you're familiar with), they make reading code harder, especially when you read other peoples code (you're reading their conventions and checking when they mean the same thing and when they mean different).
I think good docs, @types/node, and the constant we add will help the writing UX with fewer downsides.
Adding aliases would be backward compatible, but removing them would not, so I'd prefer starting with no aliases.
(I'm just another community member that wants to see node:ffi land, not a required reviewer)
| through reentrant JavaScript such as FFI callbacks. Doing so may crash the | ||
| process, produce incorrect output, or corrupt memory. | ||
|
|
||
| The `char` type follows the platform C ABI. On platforms where plain C `char` |
There was a problem hiding this comment.
Include an example (or function) to check the platform c abi?
There was a problem hiding this comment.
I think this is unnecessary. First of all, this is transparent to node:ffi so users won't really care about this. The few that might care probably know which platforms they're developing on.
There was a problem hiding this comment.
This and the request for a suffix helper are intended for code that doesn't know what platforms it will run on - I think developers would write similar code to map platform to C ABI or dll suffix which seems like a good opportunity for a built in helper.
|
|
||
| Supported fields: | ||
|
|
||
| * `result`, `return`, or `returns` for the return type. |
There was a problem hiding this comment.
Is there an explanation why there's more than one way to spell this? Compat with other ffi libraries? If so, we should document that, tho I'd rather pick one or drop compat goals.
There was a problem hiding this comment.
See above: no need to, just trying to use the principle of least surprise here. Other runtimes use different conventions so I'm trying to please anybody, since there is no hard requirement on the ABI side.
| ); | ||
| const libraryPath = path.join( | ||
| fixtureBuildDir, | ||
| process.platform === 'win32' ? 'ffi_test_library.dll' : |
There was a problem hiding this comment.
Should node:ffi export a suffix constant?
There was a problem hiding this comment.
I don't think so. This is just used in tests, I guess people know which file they are loading :)
| @@ -706,7 +719,7 @@ function initializePermission() { | |||
| const { availableFlags } = require('internal/process/permission'); | |||
| ArrayPrototypeForEach(availableFlags(), (flag) => { | |||
| const value = getOptionValue(flag); | |||
| if (value.length) { | |||
| if (value === true || value?.length) { | |||
There was a problem hiding this comment.
Why is this change required? There's already boolean permission flags
| offset, or writing through a stale pointer can corrupt memory or crash the | ||
| process. | ||
|
|
||
| ## `ffi.toString(pointer)` |
There was a problem hiding this comment.
Should this have an optional max length?
There was a problem hiding this comment.
I'm not sure to be honest. The underlying C++ method will return an empty string, if length>maxLength, which I find counter-intuitive.
I wouldn't for now, but we can eventually change in a follow up PR.
This is not ready for review yet. Just opening to see if this is something the project is still interested in.